不知道大家有沒有打過這種客服電話：

「信用卡服務請按 1，存款服務請按 2……」

「帳務問題請按 1，交易問題請按 2，掛失請按 3……」

聽到第二層、第三層的時候，我常常已經開始困惑：

所以我這個問題到底算哪一類？

假設我的問題是：

「我昨天刷了一筆錢，但今天 App 裡看不到，這算帳務問題還是交易問題？」

我明明知道自己遇到了什麼問題，卻不知道 System 把這個問題叫做什麼。

最後只好選一個最像的，如果選錯，再被轉接到另一個部門。

這其實是一個很典型的產品設計：

User 有問題
    ↓
理解 System 的分類
    ↓
選擇 Category
    ↓
System Routing
    ↓
找到負責的人

以前我們可能會想：

怎麼把分類名稱寫得更清楚？怎麼減少一層選單？

但 AI 讓我開始問另一個問題：

如果 System 已經可以理解 User 在說什麼，為什麼還需要 User 自己判斷 Category？

而這個問題，我最近在做企業內部產品時，又遇到了一次。

我們把分類整理清楚了，問題卻沒有真的消失

前陣子做一個企業內部系統時，員工有很多不同的服務與申請需求，背後也對應不同的 Process、Owner 和 Workflow。

所以我和 UX 團隊做了一件很合理的事：

重新整理 Information Architecture。

我們花時間把原本複雜的服務重新分類，希望員工可以更容易找到正確入口：

員工需求
   ↓
第一層分類
   ↓
第二層分類
   ↓
對應服務
   ↓
提單

從 UX 的角度來看，它確實比原本清楚很多。

員工也可以按照分類，一步一步找到服務並完成提單。

但 Review 的時候，老闆並沒有特別買單。

後來我才意識到：

我們解決的是「怎麼讓 User 更容易理解分類」，但沒有回答「為什麼 User 要理解這些分類？」

對 System 很清楚的詞，對 User 不一定有意義

例如企業內部可能有：

轉職 / 派任

對 System 來說，這兩個詞很重要。

因為背後可能代表不同的：

• Policy
• Approval Flow
• Owner
• Form
• Workflow

所以我們很自然會想：

那就把兩者的定義寫清楚一點。

但站在員工角度，他腦袋裡想的可能根本不是：

「我這次到底屬於轉職還是派任？」

而是：

「我要去另一個廠區工作了，接下來要辦什麼？」

就算我們把「轉職」和「派任」的定義寫得再完整，他可能還是滿頭問號。

因為這個分類不是他的語言。

我們其實是在要求 User 先學會公司的內部語言，再告訴 System 自己屬於哪一類。

這跟剛剛的信用卡客服其實是同一件事：

信用卡 User：
「我刷了一筆錢，但 App 看不到。」
        ↓
帳務？交易？

企業員工：
「我要去另一個廠區工作。」
        ↓
轉職？派任？

User 其實已經把自己的問題講得很清楚。

不清楚的是：這個問題在 System 裡叫什麼。

很多 Category，本來就是為了 System 存在

產品需要分類，當然有它的原因。

因為 System 必須知道：

• Case 要 Routing 給誰？
• 要進哪個 Workflow？
• 要查哪份 Knowledge？
• 要套用哪個 Policy？
• 報表要算在哪個 Category？

所以 Category 本身並沒有錯。

真正值得重新思考的是：

為什麼這個 Classification 的工作，要由 User 完成？

上一篇聊 Search 時，我提到：

Intent 明確，就別逼 User 聊天；Intent 模糊，也別逼 User 猜 Keyword。

到了 Category，其實也是同樣的 Product Thinking：

不要逼 User 猜 System 用什麼詞描述他的問題。

如果 User 已經可以直接說：

「我昨天刷了一筆錢，但 App 裡看不到。」

或：

「我下個月要從 A 廠區去 B 廠區工作，不知道要辦什麼。」

那剩下的 Translation，也許應該開始由 System 負責。

AI 改變的不是分類，而是誰負責分類

AI Native 的流程可以變成：

User 說明自己的問題
        ↓
Intent Understanding
        ↓
Category Classification
        ↓
Routing / Knowledge / Workflow

後台仍然可以有非常嚴謹的 Structured Data：

Intent = 工作地點異動
Category = XXX
Process = XXX
Owner = XXX

Category 沒有消失。

只是 User 不一定需要看到它。

這也呼應 Day 03 講過的一件事：

AI Native Product 不是不要結構，而是不要再要求 User 理解結構。

以前 Category 是 User Journey 的一部分。

未來很多 Category，可能更像 System 背後的 Metadata。

但不是所有 Category 都應該藏起來

這裡很容易走到另一個極端：

那以後所有分類都拿掉，全部讓 AI 判斷？

我反而不這麼認為。

因為 Category 在產品裡，其實有兩種完全不同的角色。

1. 幫 User 探索的 Category

例如外賣首頁：

火鍋｜飲料｜日式｜早餐｜甜點

今天我不知道吃什麼，看到「日式」可能突然想到：

好像可以吃壽司。

這時 Category 本身就是 Discovery Experience。

它在幫 User 理解：

「這裡有哪些選擇？」

這種 Category，我會留下來。

2. 幫 System Routing 的 Category

另一種則是：

問題類型
服務類別
申請類型
案件分類

User 通常不在乎自己屬於 Category A 還是 B。

他真正想知道的是：

我的事情到底要怎麼處理？

如果分類主要是為了 Routing、Workflow 或 Reporting，我就會優先思考：

能不能讓 System 自己判斷？

PM 可以怎麼判斷 Category 該不該留？

現在如果看到一個分類選單，我會先問四個問題：

① User 本來就理解這個分類嗎？

「火鍋 / 飲料 / 早餐」很好懂。

但「轉職 / 派任」這種來自企業流程的詞彙，User 未必真的理解。

② 它是在幫 User 探索，還是在幫 System Routing？

如果拿掉後，User 更難知道有哪些選擇，可以留下。

如果拿掉後，只是 System 少拿到一個欄位，就值得考慮自動分類。

③ 分錯的 Cost 有多高？

推薦錯一個餐飲分類，User 換一個就好。

但如果分類錯誤會導致申請走錯流程，就不能讓 AI 猜完直接送出。

可以設計成：

AI 判斷 Category
      ↓
Confidence 足夠？
   ↙          ↘
 Yes          No
  ↓            ↓
自動 Routing   Ask / Confirm

④ User 真的需要知道這個 Category 嗎？

很多時候答案其實是：不需要。

User 只需要知道：

「我說清楚發生什麼事，System 就知道接下來怎麼處理。」

Category 可能從 Navigation，變成 Metadata

我覺得這才是 AI 對分類設計真正有意思的地方。

以前 Category 常常直接長在 UI 上：

Category
   ↓
Subcategory
   ↓
Form
   ↓
Submit

未來很多場景可能變成：

User 說明需求
   ↓
AI 理解 Intent
   ↓
自動產生 Category / Metadata
   ↓
Routing / Workflow

Category 並沒有消失。

它只是從 Navigation，慢慢變成 Metadata。

這也是這次做企業產品讓我重新意識到的一件事：

我們不應該因為後台需要一個欄位，就直接在前台做一個 Dropdown。

而應該先問：

這個資訊，真的需要 User 理解並提供嗎？還是 System 自己就能判斷？

Day 06：重新檢查產品裡的每一個分類

如果今天重新 Review 一個產品，我會先把 Category 分成兩種：

所以 AI 時代，我覺得 PM 可以多問一句：

這個 Category，到底是在幫 User，還是在幫 System？

Product Principle

幫 User 探索的分類，留在前台；只為 System Routing 的分類，藏到後台。

以前我們設計產品，很常努力讓 User 學會 System 的語言。

但這次我反而開始覺得：

如果 User 已經把自己的情境說清楚了，剩下的翻譯工作，應該慢慢交還給 System。